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(54) Method of verifying downloaded software and corresponding device 



(57) The present invention relates to ensuring secu- 
rity for software downloads to a device, in which a smart 
card is used for storage of secure keys and for calcula- 
tions using the secure keys. The result of the calcula- 
tions using the smart card are passed to the device for 
comparison with calculations performed by the device 
on the downloaded software, to verify the downloaded 
software. Thus the security of the keys and calculations 
involving the secure keys are kept secure. Preferably 
root security keys stored in the smart card can be up- 
dated using communication system messaging proto- 
cols. 
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Description 

[0001] The present invention relates to a method of 
verifying software downloaded from an originator to a 
device, and to a corresponding device. In particular, the 
invention relates to download verification in standard- 
ised execution environments such as the Mobile Execu- 
tion Environment (MExE) and Java. 
[0002] Increasingly it is becoming desirable for soft- 
ware to be downloaded to a portable device over the air. 
This allows the device to be upgraded with newly re- 
leased software or enables new applications to be add- 
ed to the device as these become available. 
[0003] It is desirable that the device checks the au- 
thenticity of the downloaded software to determine 
whether, for example, the downloaded software has in- 
deed been received from a trusted sender. In addition, 
it is desirable that the downloaded software should be 
restricted to a given domain, to avoid permission viola- 
tion for the rest of the device. 

[0004] This security can be ensured by keys, which 
are stored securely in the device such that they cannot 
be read or tampered with by applications except the se- 
curity-checking environment. In addition it is desirable 
to update the keys periodically, and this must be done 
using a secure method. 

[0005] Previously, it has been suggested to imple- 
ment the security algorithms in software/hardware and 
then to protect them by hardware control on the proces- 
sor of the terminal with memory management unit. How- 
ever, this results in increased cost. In addition, the de- 
velopment of separate security hardware is undesirable. 
[0006] The Mobile Execution Environment (MExE), 
which enables software download, is currently under 
standardisation. Three class marks are defined in the 
MexE environment. Class mark 1 relates to devices uti- 
lizing the Wireless Application Protocol (WAP); class 
mark 2 relates to devices, such as personal digital as- 
sistants (pda) or laptops using standard edition JAVA™ 
(J2SE); and class mark 3 relates to small devices, such 
as mobile telephones, using micro-edition JAVA™ 
(J2ME). 

[0007] J2ME is being proposed as an environment for 
class mark 3 devices in MExE because of its small size, 
which makes it suitable for environments, such as the 
mobile communication environment for example, in 
which the available memory or processing power is lim- 
ited and the size of files must be limited. 
[0008] However, the security model for J2M E requires 
server-based p re-verification, in which a server inserts 
basic run-time security information in the software prior 
to download. The receiving device can then use the run- 
time security information to check the security of the 
download and verify the sender. 

[0009] It is desirable to increase the security provided 
for software download, particularly in a MExE class 
mark 3 environment, so that server-based verification is 
avoided and software can be downloaded from a greater 



variety of sources. 

[001 0] According to a first aspect of the present inven- 
tion, there is provided a method of verifying software 
downloaded from an originator to a device adapted to 
5 receive, in use, a smart card having at least one secure 
key stored therein, comprising: receiving software and 
security information relating to the received software; 
obtaining in the smart card a first calculation result from 
the security information using at least one secure key; 
10 obtaining in the device a second calculation result from 
calculations performed on the received software; and 
comparing in the device first and second calculation re- 
sults to verify the received software. 
[001 1 ] According to a second aspect of the invention, 
15 there is provided a device comprising: communication 
means for receiving software and security information 
relating to the received software; smart card interface 
means for passing the security information to a smart 
card coupled to the smart card interface means and for 
receiving from the smart card a first calculation result 
obtained from the security information by the smart card 
using at least one security key; means for obtaining a 
second calculation result from calculations performed 
on the received software; means for comparing first and 
second calculation results to verify the received soft- 
ware. 

[0012] For a better understanding of the present in- 
vention, and to show how it may be brought into effect 
reference will now be made, by way of example to the 
accompanying drawings in which: 

Figure 1 illustrates a known file transfer verification 
procedure; 

Figure 2 shows a communication device; 
Figure 3 illustrates a download verification proce- 
dure in accordance with the invention; 
Figure 4 illustrates message creation for transfer of 
the root key in accordance with the invention; 
Figure 5 illustrates update of the root key in accord- 
ance with the invention 

[0013] The present invention is described with refer- 
ence to the use of RSA cryptography. The RSA cryptog- 
raphy algorithm and principle are well known and there- 
fore will not be explained in detail in this document. As 
will be apparent to a skilled person, other cryptography 
techniques may also be used in accordance with the in- 
vention. 

[0014] Figure 1 illustrates a known file transfer verifi- 
cation procedure, for verifying the authenticity of a file 
transferred from an originatorto a receiver. The principle 
behind this procedure is that in addition to the transfer 
of the file 1 a second piece of information which is relat- 
ed to both the file 1 and the originator is also transferred 
between the originator and the receiver, which informa- 
tion enables the receiver to confirm that the file comes 
from the originator. In addition, the receiver possesses 
or is passed a third piece of information, which enables 
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the receiver to confirm that the originator can be trusted 
and that it is therefore safe to execute the downloaded 

file. 

[0015] In the illustrated procedure the originator gen- 
erates the second piece of information by performing an 
MD5 hash operation 10 on the file 1 to be transferred to 
create an MD5 hash result 2. The MD5 hash operation 
is well known and will not be explained further. The MD5 
hash result 2 is uniquely dependent on the file 1 and can 
be used to verify file 1 . 

[001 6] Next the originator performs an RSA algorithm 
operation 20 on the MD5 hash result 2 using the private 
key of the originator (A KPRl ) 3 to generate a signed hash 
(or digital signature) 4. The signed hash 4 thus depends 
upon the file and is signed as having been originated by 
A and can therefore act as the second piece of informa- 
tion mentioned above. The file 1 and the signed hash 4 
are transferred to the receiver resulting in a received file 
5 and a received signed hash 6. 
[001 7] I n order to verify the received file, the receiver 
independently generates two versions of the MD5 hash 
result. The first MD5 hash result 7 is generated from the 
received file 5 using a MD5 hash operation 30, and the 
second MD5 hash result 8 is obtained from the received 
signed hash 6 by performing an RSA operation 40 on 
the received signed hash 6 using the public key of the 
originator A (A Kpub ) 9 held by the receiver. The first MD5 
hash result 7 and the second MD5 hash result 8 are 
compared in a comparison operation 50 and if they are 
found to be equal, the received file 5 is authenticated 
and can be executed. 

[0018] In order for the above authentication scheme 
to work, the receiver must have authenticated access to 
the public key of the originator A (A^^). This is 
achieved in the illustrated procedure through the use of 
a certification authority. The certification authority is 
trusted by the receiver, such that received information 
signed by the certification authority is trusted by the re- 
ceiver. 

[0019] Therefore, as shown the certification authority 
performs an RSA algorithm operation 60 on the public 
key of the originator (A KPub ) 11 using the private key of 
the certification authority (CA KPR |) 12 resulting in a 
signed key 1 3 of the originator A. The signed key 1 3 and 
the certification authority public key (CA Kpub ) 14 are 
transferred to the receiver. As shown, if necessary the 
signed key 1 3 undergoes a certificate chain analysis op- 
eration 70 to obtain the received signed public key 15 
of the originator A. 

[0020] A certificate chain analysis operation is re- 
quired if the certificate authority CA is not known by the 
receiver. In this case, the certificate authority is request- 
ed to provide its public key signed by a further certificate 
authority using the private key of the further certificate 
authority. If the further certificate authority is trusted by 
the receiver, the receiver will be able to use the public 
key of the further signature authority to verify that the 
public key of the signed authority has been signed by 



the private key of the further signature authority. The re- 
ceiver can then trust the certificate authority and can use 
the received certificate authority public key. If the further 
certificate authority is not trusted by the receiver, use 

5 must be made of an additional certificate authority. 
[0021] The receiver has stored therein a root certifi- 
cation authority public key. The root certification author- 
ity is the most trusted by the receiver, and ultimately the 
stored public key of the root certification authority can 

10 be used to verify all other certification authorities in a 
certificate chain situation. 

[0022] The receiver then performs an RSA operation 
80 on the resulting signed public key of the originator 
( A KPub) ( 15 ) usin 9 tne root certification authority public 
is key (Root CA KPub ) to obtain the public key of the origi- 
nator (Akp^) 9. The public key of the originator (A KPub ) 
9 is then used in the RSA operation 40 as described 
above. 

[0023] The present invention is described below with 
reference to a communication device, such as a mobile 
telephone. However, it will be clear to a skilled person 
that the present invention is also applicable to other de- 
vices. An exemplary communication device 200 is now 
described with reference to Figure 2. 
[0024] The communication device 200 shown in Fig- 
ure 2 comprises a communication interface 210 coupled 
to an antenna 220 and to a processor 230. The proces- 
sor 230 and the communication interface 210 are also 
coupled to volatile memory 240 and to a non-volatile 
memory 250. A smart card 260 is coupled to a smart 
card interface 270, which is also coupled to the proces- 
sor 230. The smart card is equipped with its own proc- 
essor 280 and memory 290. 

[0025] The communication interface 210 comprises 
the necessary components to convert radio frequency 
signals for the communication device 200 received by 
the antenna 220 to digital signals to be stored in volatile 
memory 240 and/or non-volatile memory 250 and/or to 
be processed by processor 230, and to convert digital 
signals from the memories 240 and 250 and/or the proc- 
essor 230 to radio frequency signals to be transmitted 
by the antenna 220. Thus communication interface 210 
comprises radio frequency transmitter and receiver 
means and signal processor means, for example. 
[0026] The volatile memory 240 and non-volatile 
memory 250 are used for storing program and other da- 
ta for operation of the communication device 200. 
[0027] The smart card is preferably a subscriber 
smart card (SIM) holding subscriber information used 
by the communication device 200, for example a Sub- 
scriber Identity Module card as currently used in the Glo- 
bal System for Mobile Communications (GSM system) 
and in use or proposed for other communication sys- 
tems. However, it is possible that the smart card 260 
may be another type of smart card received in the com- 
munication device instead of, or preferably in addition 
to a SIM card, for example an electronic commerce 
smart card. 
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[0028] As indicated above, the smart card is equipped 
with its own processor 280 and memory 290, and is ca- 
pable of storing information therein and is also capable 
of carrying out operations or calculations on data re- 
ceived from the processor 230 via smart card interface 
270 and of providing data or the results of such calcu- 
lation to the processor 230 via smart card interface 270. 
[0029] The smart card is preferably removably receiv- 
able in the communication device, for example by 
means of the provision of a slot in the housing of the 
communication device 200. 

[0030] It will be appreciated by a skilled person that 
other components or arrangements of components 
within the communication device 200 are possible within 
the scope of the invention. 

[0031] The secure download procedure in accord- 
ance with the invention will now be described with ref- 
erence to Figure 3. In Figure 3 operations or data cor- 
responding to operations or data in Figure 1 have been 
given similar reference numerals. 
[0032] Figure 3 illustrates the download of an execut- 
able J2ME file in a MExE environment from an originator 
A to a device such as the communication device 200 
described above with reference to Figure 2. As shown 
in Figure 3, box 3260 represents operations carried out 
and data stored in the smart card 260 of the communi- 
cation device 200 shown in Figure 2, and the remaining 
operation and data storage is carried out in the rest of 
the communication device 200 shown in Figure 2. 
[0033] As illustrated in Figure 2, the smart card 260 
has no direct communications capability. Instead, the 
relevant data received by the communication device is 
passed by the processor 230 to the smart card 260 for 
storage therein and operation thereon. 
[0034] In the procedure illustrated in Figure 3, the 
originator A performs an MD5 hash operation 31 0 on a 
file 31 to be transferred to create an MD5 hash result 
32. As explained above, the MD5 hash result 32 is 
uniquely dependent on the file 31 and can be used to 
verify file 31. 

[0035] Next the originator A performs an RSA algo- 
rithm operation 320 on the MD5 hash result 32 using the 
private key of the originator (A KPRI ) 33 to generate a 
signed hash 34. The signed hash 34 thus depends upon 
the file and is signed as having been originated by A and 
can therefore act as the second piece of information 
mentioned above. The file 31 and the signed hash 34 
are then sent to the communication device 200 resulting 
in a received file 35 and a received signed hash 36. File 
35 is received using antenna 220 and communication 
interface 21 0 and is stored by the processor 230 in the 
volatile memory 240. In contrast, the signed hash 34 is 
received using antenna 220 and communication inter- 
face 21 0 and is sent by the processor 230 to the smart 
card 260 via smart card interface 270 and is stored in 
the smart card memory 290. 

[0036] As described above, in order to verify the re- 
ceived file, two versions of the MD5 hash result must be 



independently generated and compared. The first MD5 
hash result 37 is generated by the communication de- 
vice processor 230 from the received file 35 using a MD5 
hash operation 330. 

5 [0037] The second MD5 hash result 38 is obtained by 
the smart card from the received signed hash 36. The 
smart card processor 280 performs an RSA operation 
340 on the received signed hash 36 stored in the smart 
card memory 390 using the public key of the originator 

10 A ( A K P ub) 39 stored in the smart card memory 290, as 
will be explained later. 

[0038] The second MD5 hash result 38 is passed by 
the smart card processor 280 to the communication de- 
vice processor 230 and the communication device proo- 
fs essor 230 compares the first MD5 hash result 37 and 
the second MD5 hash result 38, calculated in the smart 
card 260, in a comparison operation 350. If the first MD5 
hash result 37 and the second MD5 hash result 38 are 
found to be equal, the received file 35 is authenticated 

20 and can be executed. 

[0039] In this arrangement, the smart card 260 must 
have authenticated access to the public key of the orig- 
inator A (A,^^). This is achieved in the illustrated pro- 
cedure according to Figure 3 through the use of the root 

25 certification authority public key stored in the smart card 
memory 290. The root certification authority is trusted 
by the communications device, such that received infor- 
mation signed by the certification authority is trusted. 
[0040] In this context, there may be more than one 

30 root certification authority. For example in the context of 
a mobile telephone the manufacturer and/or the opera- 
tor can act as a root authority. In addition, it is possible 
to specify one or more trusted third parties as root cer- 
tification authorities. The public key for each of the root 

35 certification authorities (eg the operator public root key 
(OPRK); the manufacturer public root key (MPRK); and 
third party public root key (TPRK)) is stored in the smart 
card of the communication device 200, for example dur- 
ing provisioning of a mobile telephone SIM card. 

40 [0041] In order that the smart card 260 has authenti- 
cated access to the public key of the originator A (A Kpub ), 
as shown the root certification authority performs an 
RSA algorithm operation 360 on the public key of the 
originator (A KPub ) 31 1 using the private key of the certi- 

45 fication authority (RootCA KPR ,) 312 resulting in a certif- 
icate from A 321 signed by the root certification author- 
ity. This certificate 321 is sent to the communications 
device 200, is received using antenna 220 and commu- 
nication interface 210 and is sent by the processor 230 

50 to the smart card 260 via smart card interface 270 and 
is stored in the smart card memory 290 as certificate 
322. 

[0042] The Root certification authority public key 
(RootCA KPub ) 332 is already stored in the smart card 
55 memory 290, as indicated above. The smart card proc- 
essor can perform an RSA operation 380 on the re- 
ceived certificate 322 using the Root Certification Au- 
thority public key (RootCA KPub ) 332 to obtain the public 
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key of the originator A (A,^^ 39. The smart card proc- 
essor can then use the obtained public key of the origi- 
nator A (A Kpub ) 39 and the received signed hash 36 in 
RSA operation 340 to obtain the smart card MD5 hash 
value 38, as outlined above. 

[0043] Also shown in Figure 3 is the transfer of the 
Root Certification Authority public key (RootCA KPub ) 
331 to the communications device for storage in the 
smart card memory as Root Certification Authority pub- 
lic key (RootCAKput,) 332 - !t is desirable to update the 
root certification authority keys periodically in a secure 
manner otherwise the security of the system will be com- 
promised. 

[0044] A preferred mechanism for the secure transfer 
of a Root public key (for example OPRK, MPRK, TPRK) 
using communication system messaging technology 
will now be explained with reference to Figures 4 and 5. 
[0045] Figure 4 illustrates message creation for trans- 
fer of a root key, for example the operator public root 
key (OPRK), to the smart card 360 in accordance with 
the invention. In this exemplary arrangement, the up- 
date is achieved using a SMS message as provided in 
the GSM/UMTS systems, although other messaging 
techniques could be used. 

[0046] An RSA operation is performed on the new 
OPRK 41 with the operator's private root key 42 corre- 
sponding to the old OPRK stored in the smart card 360. 
As mentioned earlier, the old OPRK may have been 
stored in the smart card 360 during provisioning, or dur- 
ing a previous update of the root key. The resulting 
signed new operator public root key 44 is included in an 
SMS message 45 to be sent to the communication de- 
vice. The SMS message 45 has an SMS header portion 
451 and SMS download command 452 in addition to the 
signed new operator public root key 44. The SMS mes- 
sage in encrypted by the communication system prior 
to being sent to the communication device. 
[0047] Figure 5 illustrates update of the root key in the 
communication device in accordance with an embodi- 
ment of the invention. In this exemplary embodiment of 
the invention, the SMS message 45 sent by the network 
500 to the communication device 200 is passed to the 
smart card 260. Once the encrypted SMS message 45 
is received in the smart card 260, the smart card 260 
undertakes an SMS message analysis and memory up- 
date procedure 51 . 

[0048] In the SMS message analysis and memory up- 
date procedure 51 the SMS message is initially decrypt- 
ed and the SMS message is analysed. The download 
command 452 instructs the smart card 260 that a new 
OPRK is being sent to the smart card 260. The smart 
card 260 performs an RSA operation on the received 
signed new OPRK using the old OPRK already stored 
in the smart card 260 to verify the identity of the sender. 
The OPRK stored in the smart card can then be updated 
using the new value. Preferably a confirmation message 
52 is sent from the smart card 260 to the network using 
the communication interface 210 of the communication 



device 200. 

[0049] Although the update of the operator public root 
key (OPRK) has been described above, it would be pos- 
sible to update any root key stored in the smart card in 

5 the same way. 

[0050] In accordance with an alternative embodiment 
of the invention, the manufacturer root public key may 
be stored partially in the smart card memory and par- 
tially in the communications device memory. This ar- 

10 rangement is more secure since the communication de- 
vice then contributes to ensuring the security of down- 
load in the manufacturer domain using the manufacturer 
root public key. This helps to prevent an insecure smart 
card from changing the manufacturer public root key via 

15 download authorization. 

[0051] Thus the present invention proposes a solution 
to ensuring security for software downloads to a device, 
in which a smart card is used for storage of secure keys 
and for calculations using the secure keys. The result of 

20 the calculations using the smart card are passed to the 
device for comparison with calculations performed by 
the device on the downloaded software, to verify the 
downloaded software. 

[0052] Since the secure keys are stored on the smart 
25 card and calculations involving the secure keys are per- 
formed by the smart card, the security of the secure keys 
can be ensured. In addition, the result of the calculation 
performed on the received file by the device is not 
passed to the smart card. 
30 [0053] As will be apparent to a skilled person, the in- 
vention could be implemented in a different form from 
that shown herein, and so the invention is intended to 
encompass all arrangements and variations within the 
scope of the appended claims. 

35 

Claims 

1 . A method of verifying software downloaded from an 
40 originator to a device adapted to receive, in use, a 
smart card having at least one secure key stored 
therein, comprising: 

receiving software and security information re- 
45 lating to the received software; 

obtaining in the smart card a first calculation re- 
sult from the security information using at least 
one secure key; 

obtaining in the device a second calculation re- 
50 suit from calculations performed on the re- 

ceived software; and 

comparing in the device first and second calcu- 
lation results to verify the received software. 

55 2. The method as claimed in claim 1 , further compris- 
ing the steps of; 

receiving additional signed originator key infor- 
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mation; 

obtaining, in the smart card, originator key in- 
formation from the received signed originator 
key information using a root security key stored 
therein; and s 
obtaining in the smart card the first calculation 
result from the security information using the 
originator key information. 

3. The method as claimed in claim 2 wherein the root 10 
security key stored in the smart card is updated by 

receiving a root security key update message 
containing a new root security key; 

verifying the new root security key using the 
existing root security key stored in the smart card; *5 

storing the new root security key in the smart 

card. 



the smart card interface passes the root se- 
curity key update message to the smart card, which 
verifies the new root security key using the existing 
root security key stored in the smart card; and 
stores the new root security key in the smart card. 

9. The device as claimed in claim 7 or 8, wherein the 
device comprises storage means and part of the 
root security key is stored in the smart card and part 
of the root security key is stored in the storage 
means. 

10. The device as claimed in one of claims 6-9, wherein 
the smart card is a Subscriber Identity Module (SIM) 
card. 



4. The method as claimed in claim 2 or 3, wherein part 
of the root security key is stored in the smart card 20 
and part of the root security key is stored in the de- 
vice. 



5. The method as claimed in any preceding claim, 
wherein the smart card is a Subscriber Identity Mod- 25 
ule (SIM) card 

6. A device comprising 

communication means for receiving software 
and security information relating to the received 30 
software; 

smart card interface means for passing the 
security information to a smart card coupled to the 
smart card interface means and for receiving from 
the smart card a first calculation result obtained 35 
from the security information by the smart card us- 
ing at least one security key; 

means for obtaining a second calculation re- 
sult from calculations performed on the received 
software; 40 

means for comparing first and second calcu- 
lation results to verify the received software. 

7. The device as claimed in claim 6 wherein 

the communications means also receives ad- *5 
ditional signed originator key information; and 

the smart card interface also passes the ad- 
ditional signed originator key information to the 
smart card, which obtains originator key information 
from the received signed originator key information 50 
using a root security key stored therein; and obtains 
the first calculation result from the security informa- 
tion using the originator key information. 

8. The device as claimed in claim 7 wherein 55 

the communications means also receives a 
root security key update message containing a new 
root security key; and 
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